Payment-driven sourcing

ABSTRACT

Systems, methods and products for one embodiment comprises a method including providing a demand model which generates a payment in response to receiving input identifying a consumer profile and a vehicle type. A cashflow model is provided, and in response to receiving the payment output by the demand model and a desired return on a converted vehicle transaction, the cashflow model generates an acquisition price as an output. A comparison engine is provided which, in response to receiving the acquisition price output by the cashflow model, retrieves vehicle inventory records and compares a corresponding purchase price to the acquisition price to determine whether the corresponding vehicle is qualified. A list of qualified vehicles for a given consumer profile and vehicle type is stored and used to generate real time displays of qualified vehicles (with no unqualified vehicles) in response to a request from a specific consumer having this profile.

RELATED APPLICATIONS

This application claims priority under 35 U.S.C. § 119(e) to UnitedStates Provisional Patent Application No. 62/868,535, entitled“PAYMENT-DRIVEN SOURCING”, filed Jun. 28, 2019, and U.S. ProvisionalPatent Application No. 62/883,374, entitled “DEMAND-BASED PRICING”,filed Aug. 6, 2019, which are fully incorporated herein by reference forall purposes.

TECHNICAL FIELD

The present disclosure relates generally to the field of data processingsystems and methods, and more particularly to data processing systemsand methods for determining requirements associated with a consumer andan operator of an automotive data processing system, identifyingvehicles that are available to the automotive data processing systemfrom one or more dealers, determining which of the available vehiclesmeet the requirements of the consumer and system operator, andgenerating displays that include only ones of the available vehiclesthat meet the identified requirements.

BACKGROUND

Internet-based systems and other computer systems that facilitatepurchasing (buying or leasing) various goods and services from multiplesellers have become increasingly popular tools for both consumers andsellers. Intermediary search sites allow users to search for items(e.g., vehicles) from a large number of available items. When a userselects a vehicle, the intermediary site typically puts the buyer intouch with the dealer to finalize a business transaction on the vehicle.The consumer may schedule a test drive with the dealership and maythereafter choose to, for example, lease the vehicle. In order tocomplete the lease transaction, the lease payments and the residualvalue of the vehicle must typically be determined.

In many conventional internet-based systems for facilitating vehiclepurchase or lease transactions, the operators of these systems may becaught in the middle between sellers that want to get high prices fortheir vehicles and consumers who want to obtain the vehicles at thelowest possible price. The system operator's costs to operate the systemand facilitate the transactions may be constrained by the competinginterests of the sellers and consumers, so that it is not profitable toprovide their services in facilitating the transactions (or not asprofitable as desired). Conventional systems do not provide the abilityto source the vehicles (purchase them from sellers) in a way thatensures that the system achieves a desired return on the transactions.

SUMMARY

Embodiments of the present invention are designed to enable acquisitionof inventory items at prices which meet a system operator's businessgoals as well as a consumer's payment needs. Embodiments disclosedherein also provide means for rapidly identifying, retrieving andproviding to consumers items which meet these requirements.

The present systems and methods use information relating to payments bythe consumer, as well as information relating to the system operator'sservices (e.g., a required level of profitability) to determine which ofa seller's products meet the constraints associated with both theconsumer and the system operator. Then, these products are presented tothe consumer so that the system operator can be confident that its ownrequirements, such as a desired net return, can be met. In oneembodiment, a consumer-facing price is determined without regard to theprice for a vehicle set by a seller. The consumer-facing price is usedin conjunction with expense information and a desired rate of return todetermine a target vehicle acquisition price. This target price is thencompared to prices which are set for vehicles by their respectivesellers in order to determine which of the vehicles are priced at orbelow the target and may be presented to the consumer.

In one exemplary method, a demand model is used to determine a consumerpayment without regard to particular vehicles that may be available tothe consumer. The demand model uses historical transaction data todetermine the demand for a particular type of vehicle with respect to aparticular type of consumer. Based on the historical data, it can bedetermined how much this type of consumer is willing to pay for thistype of vehicle. The resulting payment information can be provided to acash flow model that also accepts a return-on-investment input. The cashflow model generates an acquisition price at which this type of vehiclecan be acquired for lease to this type of consumer, while meeting thereturn requirements of the system operator. Again, this acquisitionprice is determined without regard to particular vehicles that may beavailable to the consumer. This acquisition price can then be comparedto the vehicles of the indicated type that are available through thesystem. Those of the available vehicles which have a price that is equalto or less than the computed acquisition price are then made availableto display to the identified type of consumer, while vehicles which haveprices greater than the acquisition price are blocked from beingdisplayed. The qualified vehicles (those which are available to thisconsumer type) may be contained in a list associated with the consumertype so that when a specific consumer who is identified as this type ofconsumer interacts with the system, the qualified vehicles for theconsumer type can be quickly identified and presented to the specificconsumer.

In one embodiment, this method is implemented in a rules-based dataprocessing system which may include a processor and a memory coupled tothe processor to store a set of computer instructions executable by theprocessor. The system uses a demand model to determine a monthly paymentcorresponding to a given consumer profile and a given vehicle type. Themonthly payment is provided to a cashflow model, along with an expectedreturn value, and the cashflow model produces an acquisition value thatcorresponds to the received monthly payment and expected return values.The acquisition value is then compared to a set of inventory vehicles todetermine whether purchase prices of the inventory vehicles are lessthan or equal to the acquisition value. Vehicles for which thecorresponding purchase price is less than or equal to the acquisitionvalue (qualified vehicles) are made available for display to a consumer.Vehicles for which the corresponding purchase price is greater than theacquisition value are blocked from being displayed to the consumer.Identifiers for qualified vehicles may be stored in a list that isassociated with the consumer profile so that the vehicles can be quicklyidentified when a consumer having the corresponding consumer profileuses the system.

One embodiment comprises an automotive data processing system having oneor more processors that are communicatively coupled to one or more datastorage devices. The processors are coupled to a non-transitorycomputer-readable medium that stores instructions which are executableby the processor to cause the processor to execute a demand model, acashflow model and a comparison engine. The demand model is configuredto, in response to receiving input identifying a consumer profile and avehicle type, generate a corresponding payment as an output. Thecashflow model receives the payment as an input and, in response to thisinput and input identifying a desired return on a converted vehicletransaction, generates an acquisition price as an output. The comparisonengine is configured to receiving the acquisition price output by thecashflow model and to retrieve a set of vehicle inventory records and,for each of the vehicle inventory records. The comparison engine thencompares a purchase price of each vehicle inventory record to theacquisition price and generates an indication of whether or not avehicle corresponding to the vehicle inventory record is qualified. Inone embodiment, the comparison engine determines that each vehicle isqualified if the corresponding purchase price is no more than theacquisition price. Otherwise, the vehicle is disqualified. A list ofqualified vehicles corresponding to the consumer profile and a vehicletype is then generated. This list may be stored by the system for lateruse in generating real time displays of qualified vehicles in responseto a request from a specific consumer (where unqualified vehicles areexcluded from the displays).

In some embodiments, the demand model is configured to generate thepayment by identifying, in a collection of historical transactionrecords, a subset of the historical transaction records that correspondto a specific combination of the consumer profile and the vehicle type.This subset of historical transaction records is ranked by correspondingprices, and a target price corresponding to a desired percentile ofconverted transactions represented by the historical transaction recordsis selected as the payment for the specified consumer profile andvehicle type. In one embodiment, a list of qualified vehicles is createdfor each of a plurality of unique combinations of consumer profiles andvehicle types. In response to a user request of a specific consumer, acorresponding one of the consumer profiles that is associated with thespecific consumer is identified. A specific vehicle type associated withthe user request is also identified. Then, one of the lists of qualifiedvehicles which corresponds to the identified consumer profile andvehicle type is retrieved. This list of qualified vehicles is used togenerate a display which is presented in a user interface of a clientcomputing device. The display includes one or more qualified vehiclesfrom the retrieved list, but excludes disqualified vehicles.

It should be noted that, while the embodiments herein are described interms of leasing vehicles, alternative embodiments may be used in thesale of vehicles, or in the sale or lease of items other than vehicles.

Other embodiments are also possible.

BRIEF DESCRIPTION OF THE FIGURES

The drawings accompanying and forming part of this specification areincluded to depict certain aspects of the invention. A clearerimpression of the invention, and of the components and operation ofsystems provided with the invention, will become more readily apparentby referring to the exemplary, and therefore non-limiting, embodimentsillustrated in the drawings, wherein identical reference numeralsdesignate the same components. Note that the features illustrated in thedrawings are not necessarily drawn to scale.

FIG. 1 is a high level block diagram of one embodiment of a networktopology.

FIG. 2 is a diagram illustrating the operation of an automotive dataprocessing system to generate an acquisition price for a vehicle inaccordance with one embodiment.

FIG. 3 is a flow diagram illustrating the generation of an acquisitionprice for a vehicle in accordance with one embodiment.

FIG. 4 is a diagram illustrating the use of the generated acquisitionprice by the vehicle data system to identify qualified vehicles inaccordance with one embodiment.

FIG. 5 is a flow diagram illustrating the use of a generated acquisitionprice to identify qualified vehicles in accordance with one embodiment.

FIG. 6 is a flow diagram illustrating the use of a list of qualifiedvehicles to generate displays responsive to a consumer having a givenprofile in accordance with one embodiment.

FIG. 7 is a diagrammatic representation of a distributed networkcomputing environment in which some embodiments may be implemented.

DETAILED DESCRIPTION

The invention and various features and advantageous details thereof areexplained more fully with reference to the exemplary, and thereforenon-limiting, embodiments illustrated in the accompanying drawings anddetailed in the following description and appendices. It should beunderstood, however, that the detailed description and the specificexamples, while indicating the preferred embodiments, are given by wayof illustration only and not by way of limitation. Descriptions of knownprogramming techniques, computer software, hardware, operating platformsand protocols may be omitted so as not to unnecessarily obscure thedisclosure in detail. Various substitutions, modifications, additionsand/or rearrangements within the spirit and/or scope of the underlyinginventive concept will become apparent to those skilled in the art fromthis disclosure.

The present disclosure is directed to systems and methods for enablingconsumers to purchase or lease items such as vehicles online. Forpurposes of clarity, the systems and methods described herein will focuson the leasing of vehicles to consumers, but other embodiments mayinvolve the leasing or purchase of vehicles or other items.

An automotive data processing system is configured to interact withconsumers and vehicle sellers (e.g., automotive dealerships) via clientapplications running on the respective client devices of the users. Thepresent systems and methods enable sellers to present vehicles that areavailable for lease to consumers. The sellers set purchase prices forthe vehicles that are available through the system. Consumers may viewone or more of the vehicles and may choose to lease one of the vehiclesthrough the system. If this is the case, the automotive data processingsystem may perform various processing to facilitate the consumer's leaseof the vehicle. In one embodiment, if the consumer wishes to proceedwith the lease transaction, the selected vehicle is purchased by theoperator of the automotive data processing system and is then leased tothe consumer.

The system operator is compensated for the services that are provided inassociation with the lease transaction(s) by pricing the vehicle leaseto the consumer at a level which is high enough that it is expected tocover the price at which the vehicle was purchased from the originalseller and the associated costs (e.g., cost of capital, marketing,origination, servicing, depreciation, liquidation) and a net return,less the residual value. It is desirable for the operator of theautomotive data processing system to be able to ensure that theacquisition price (the price at which the vehicle is required from theoriginal seller) is low enough that the system operator makes a desiredreturn on the vehicle. Because the vehicle seller, rather than thesystem operator, sets the price at which the vehicle may be acquired bythe system operator, the system operator conventionally has no controlover this price. The present systems and methods, however, provide meansto ensure that the acquisition price is low enough to achieve thedesired return on vehicles leased using the system.

The present systems and methods effectively achieve control of theacquisition prices of vehicles that may be leased by consumers bydetermining the payments that can be made by consumers, determining thedesired return on the system operators investment in the leasedvehicles, determining the acquisition price that is necessary to achievethe desired return, and limiting the vehicles that are available throughthe system only to those which are priced to provide the desired return.The present systems and methods use a demand model which determines thepayment corresponding to a particular type of consumer and a particulartype of vehicle, then providing this payment and a desired return to acash flow model, which then determines a required acquisition price forthat type of vehicle. The computed acquisition price can then becompared to vehicles of this type which have been made available bysellers through the system. Available vehicles which have prices at orbelow the acquisition price may be displayed to consumers who maypotentially lease the vehicles, while available vehicles that haveprices above the acquisition price are not displayed. Thus, it will beassured that any lease transaction that may be completed through thesystem will provide the desired return on the acquisition cost.

Some embodiments of the present systems and methods can be implementedin a data processing system that automates and facilitates a leasingprocess, including inventory selection, financing qualification anddocument generation. In an exemplary embodiment, the system facilitatesselection of a vehicle by providing vehicle information to a consumerthrough an interface on a mobile device. In this context, a “consumer”is any individual, group of individuals, or business entity seeking tolease a vehicle (or other asset) through the system. The consumer mayselect a particular vehicle that is used as the basis for determiningsimilarity (i.e., the other vehicles are compared to the selectedvehicle). The similarity scores are used to identify vehicles similar tothe consumer-selected vehicle, and the similar vehicles are presented tothe consumer to facilitate the consumer's search for a vehicle that theconsumer may wish to lease.

Embodiments of a system for facilitating transactions may be implementedin a network topology. FIG. 1 is a high level block diagram of oneembodiment of an example topology. The network topology of FIG. 1comprises an automotive data processing system 100 which is coupledthrough network 105 to client computing devices 110 (e.g. computersystems, personal data assistants, smart phones or other clientcomputing devices). Network 105 may be, for example, a wireless orwireline communication network such as the Internet or wide area network(WAN), publicly switched telephone network (PSTN) or any other type ofcommunication link. The system may further include one or moreinformation provider systems 120, one or more dealer management systems(DMS) 122, inventory systems 124, department of motor vehicles (DMV)systems 126 or other systems.

Automotive data processing system 100 may provide a comprehensivecomputer system for automating and facilitating a leasing processincluding inventory selection, financing qualification, documentgeneration and transaction finalization, as described in detail in U.S.Patent Application Pub. No. 2018/0204281, which is hereby incorporatedby reference. The present disclosure focuses primarily on aspects of thesystem involving inventory selection, and more particularly componentsof the system relating to the ranking of displayed inventory items, thetracking of user actions associated with the displayed inventory items,and tuning of the ranking engine that generates the ranking of thedisplayed inventory items.

Using a client application 114 executing on a client device 110, aconsumer user may search dealer inventory, apply for financing, select avehicle of interest from a dealer and review and execute documentsrelated to the lease of the vehicle, and execute automated clearinghousing (ACH) transactions through automotive data processing system 100to complete the transaction.

Turning briefly to the various other entities in the topology FIG. 1,dealers may use a dealer management system (“DMS”) 122 to track orotherwise manage sales, finance, parts, service, inventory and backoffice administration needs. Since many DMS 122 are Active Server Pages(ASP) based, data may be obtained directly from a DMS 122 with a “key”(for example, an ID and Password with set permissions within the DMS122) that enables data to be retrieved from the DMS 122. Many dealersmay also have one or more web sites which may be accessed over network105, where inventory and pricing data may be presented on those websites.

Inventory systems 124 may be systems of, for example, one or moreinventory polling companies, inventory management companies or listingaggregators which may obtain and store inventory data from one or moreof dealers (for example, obtaining such data from DMS 122). Inventorypolling companies are typically commissioned by the dealer to pull datafrom a DMS 122 and format the data for use on websites and by othersystems. Inventory systems 124 may provide information on inventoryvehicles that is used in the ranking of the vehicles when they arepresented to a consumer, such as prices of the vehicles and locations ofthe vehicles.

DMV systems 126 may collectively include systems for any type ofgovernment entity to which a user provides data related to a vehicle.For example, when a user purchases a vehicle it must be registered withthe state (for example, DMV, Secretary of State, etc.) for tax andtitling purposes. This data typically includes vehicle features (forexample, model year, make, model, mileage, etc.) and sales transactionprices for tax purposes. Additionally, DMVs may maintain tax records ofused vehicle transactions, inspection, mileages, etc.).

Information provider systems 120 may be systems of entities that provideinformation used in approving a user or lease. Examples of informationprovider systems 120 may include computer systems controlled by creditbureaus, fraud and ID vendors, vehicle data vendors or financialinstitutions. A financial institution may be any entity such as a bank,savings and loan, credit union, etc. that provides any type of financialservices to a participant involved in the lease of a vehicle.Information provider systems 120 may comprise any number of othervarious sources accessible over network 105, which may provide othertypes of desired data, for example, data used in identity verification,fraud detection, credit checks, credit risk predictions, incomepredictions, affordability determinations, residual value determinationsor other processes.

Automotive data processing system 100 utilizes interfaces configured to,for example, receive and respond to queries from users at clientcomputing devices 110, interface with information provider systems 120,DMS 122, inventory systems 124 and DMV systems 126, obtain data from orprovide data obtained or determined by automotive data processing system100 to any of information provider systems 120, DMS 122, inventorysystems 124, DMV systems 126. It will be understood that the particularinterface utilized in a given context may depend on the functionalitybeing implemented by automotive data processing system 100, the type ofnetwork utilized to communicate with any particular entity, the type ofdata to be obtained or presented, the time interval at which data isobtained from the entities, the types of systems utilized at the variousentities, etc. Thus, these interfaces may include, for example, webpages, web services, a data entry or database application to which datacan be entered or otherwise accessed by an operator, APIs, libraries orother type of interface which it is desired to utilize in a particularcontext.

Client computing devices 110, 111 may comprise one or more computersystems with central processing units executing instructions embodied onone or more computer readable media where the instructions areconfigured to interface with automotive data processing system 100. Aclient computing device 110, 111 may comprise, for example, a desktop,laptop, smart phone or other device. According to one embodiment, aclient computing device 110 is a mobile device that has a touchscreendisplay and relies on a virtual keyboard for consumer data input. Clientapplication 114 may be a mobile application (“mobile app”) that runs ina mobile operating system (e.g., Android OS, iOS), and is specificallyconfigured to interface with automotive data processing system 100 togenerate application pages for display to a consumer. In anotherembodiment, the client application 114 may be a web browser on a desktopcomputer or mobile device. A client computing device 111 may run anapplication through which a dealer portal can be accessed.

In accordance with one embodiment, a consumer can utilize clientapplication 114 to register with automotive data processing system 100,view inventory, select a vehicle, apply for financing, review documentsand finalize a sales transaction through a low friction mobile apprunning on a smart phone. Client application 114 can be configured withan interface module 115 to communicate data to/from automotive dataprocessing system 100 and generate a user interface for inputting one ormore pieces of information or displaying information received fromautomotive data processing system 100. In some embodiments, theapplication 114 may comprise a set of application pages through whichapplication 114 collects information from the consumer or which clientapplication 114 populates with data provided via an interface.Application 114 may collect information that is manually input by theconsumer so that it can be processed by automotive data processingsystem 100 with other information associated with the consumer. Thisinformation can be used to determine, for example, the consumer'squalification for a vehicle lease, financing options available to theconsumer, or pricing for particular vehicles. Application 114 may alsocollect automatically information associated with the consumer's viewsof displayed vehicles and identification of particular vehicles asfavorites or subscribed vehicles. This information may be used to tunethe weights that are applied to signals input to a ranking engine thatdetermines an order in which vehicles are displayed to the consumer.

Vehicle data application 150 can comprise a set of processing modules toprocess obtained data or processed data to generate further processeddata. Different combinations of hardware, software, and/or firmware maybe provided to enable interconnection between different modules of thesystem to provide for the obtaining of input information, processing ofinformation and generating outputs.

In the embodiment of FIG. 1, vehicle data application 150 includes ademand model 152 and a cashflow module 154. Demand model 152 useshistorical transaction data 134 stored in data store 130 to determinethe payments for a consumer having a particular profile that will belikely to result in a completed lease transaction. Cashflow model 154uses contract records 132 and information on customers' performance onthose contracts 133 to take input payment information from demand model152 and information on the desired return for a transaction so that itcan determine an acquisition price for particular types of vehicles.This acquisition price is compared to prices set by sellers forinventory vehicles 131 in order to determine which of these vehicles ispriced to meet the return requirement. A list of qualified vehicles 135for the consumer profile (vehicles that are priced at or below theacquisition price for that type of vehicle) is stored in data store 130for quick retrieval when a consumer uses the system.

Vehicle data application 150 may also include various other moduleswhich are not described in detail herein. These modules may include, forexample, dealer interaction modules, user interaction modules, inventorymodules, order modules, financing modules, document modules, and variousother modules that may be necessary or desirable to perform thefunctions of the vehicle data application.

Referring to FIG. 2, a diagram illustrating the flow of data through ademand model and a cashflow model in accordance with one embodiment isshown. As depicted in this figure, a consumer profile 202 and a vehicletype 204 are provided to a demand model 152. The consumer profile mayinclude various types of information, such as income, credit score,rent, debt-to-income ratio, etc. Alternatively, the consumer profile maycomprise an indication of a particular classification or categorizationof the consumer, where the classification may be used to identify agroup or class of consumer whose behavior can be collectivelycharacterized.

In one embodiment, the acquisition price is determined without regard toa specific consumer. In other words, the consumer profile is a uniqueclassification or set of characteristics that describe a segment of theconsumer population. The consumer profile may be defined by particularvalues or ranges of values for one or more consumer characteristics(e.g., income, credit score, rent, debt-to-income ratio). Thesecharacteristics are used to identify subsets of the historicaltransaction data that are used as the basis for the demand model. Eachsubset of the data is analyzed to determine the payments that areassociated with the corresponding consumer profile and various vehicletypes. Because personally identifiable consumer information is oftenprotected by applicable laws and/or regulations, one embodimentgenerates its own internal risk scores for consumers based on availableinformation and then uses the consumer's internal risk score and stateas a consumer profile.

The vehicle type provided to the demand model does not identify aspecific vehicle, but instead identifies a class or group of vehicles.The vehicle type may, for example, be identified by variouscharacteristics of a class of vehicles, such as the body style (e.g.,sedan, coupe, SUV, etc.), size (e.g., sub-compact, compact, mid-size,etc.), and the like. The particular characteristics that are used toidentify the vehicle type may differ from one embodiment to another,depending upon the requirements of the demand model. Thesecharacteristics may also be encoded into a record or number such as avehicle identification number, or VIN number. One embodiment may use a“VIN10”, which comprises the first 10 digits of the VIN. This numberidentifies such things as the manufacturer, model, body type and modelyear (the remainder of the VIN—digits 11-17—contains a serial numberthat can be used to identify the specific vehicle associated with thetransaction record, but which is not necessary in this embodiment).

The vehicle type may be derived from the user request to access theautomotive data processing system. The user may, for example, explicitlyidentify a vehicle type when the request is initiated, so the requestitself may identify the vehicle type (e.g., by including a VIN thatidentifies the vehicle type). In one embodiment, the VIN is decoded toidentify information such as the make, model, model year, trim, andequipment of the vehicle. Alternatively, the user may have searched forparticular vehicles or for vehicles with particular characteristics, andthis search activity may be used to identify a vehicle type which canthen be provided to the demand model.

Demand model 152 is derived from historical transaction data thatidentifies lease transactions. Each of the transaction records thatcontain the transaction data has associated consumer information,vehicle type information, and payment information. This information isanalyzed to determine the payment levels at which consumers havingparticular profiles are likely to complete lease transactions forparticular types of vehicles. Various different algorithms may be usedto identify the payments corresponding to the different consumerprofiles and vehicle types. For example, in one embodiment, thehistorical transaction data may be segregated by consumer profileclassifications, and further segregated into vehicle types. Then, foreach combination of a particular consumer profile classification and aparticular vehicle type, the data for this combination may be examinedto identify a payment level (e.g., maximum monthly payment) at which apredetermined number of transactions are converted. The model in thisexample might therefore be a table that stores payment valuescorresponding to the consumer profile classifications and vehicle types.

Demand model 152 is designed to receive consumer profile 202 and vehicletype 204 as inputs, and to provide the corresponding payment 206 as anoutput. In the example of a demand model that comprises a table storingpayment values, the input consumer profile and vehicle type may be usedto look up a corresponding payment value in the table. In alternativeembodiments, the demand model may be a more complex structure, and itmay be necessary to compute the payment value after the consumer profileand vehicle type are input to the model. It should be noted that thepayment generated using the demand model is consumer-facing and isgenerated without regard to any particular vehicle that is being offeredfor sale or lease, or any costs that may be associated with selling orleasing a vehicle.

The payment 206 that is produced by demand model 152 corresponding tothe identified consumer profile 202 and vehicle type 204 is then itselfprovided as an input to a cash flow model 154. In one embodiment, adesired return 208 is also input to the cash flow model. Cash flow model154 is derived in this embodiment from historical contract performancedata which is collected by the system. This data is analyzed todetermine the costs associated with transactions involving particulartypes of vehicles. In one embodiment, this is accomplished using anensemble of a logistic regression and a tree-based model that use price,make, model, and state as inputs. The cash flow model is designed todetermine, based upon the input return information 208 and the paymentinformation 206 from the demand model a maximum acquisition price 210that is necessary to provide the desired return for the particular typeof vehicle at the payment level indicated by the demand model.Acquisition price 210, similar to the customer-facing payment 206, isindependent of any particular vehicle that may be available for sale onthe system.

The cash flow model is a hybrid of two models. The first model is asurvival model, which is a logistic regression trained on historicalpayment data to determine the customer and vehicle attributes thatpredict the probability of voluntarily returning a car or defaulting onthe contract in each time period. This may be replaced with a neuralnetwork survival model in some alternative embodiments. The second modelis a unit economics model, which is a mechanistic model capturing thecash inflows and outflows that comprise the relevant economics. Thesurvival model and the unit economics model are combined to produce aprobability weighted set of cash flows that describe the expectedfinancial performance of a given deal.

Referring to FIG. 3, a flow diagram illustrating a method for generatinga vehicle acquisition price in an automotive data processing system inaccordance with one embodiment is shown. In this method, a consumerprofile and a desired vehicle type are provided to a demand model (302).The demand model processes the input consumer profile and vehicle typeand generates a payment as an output (304). The payment generated by thedemand model and a desired rate of return are then provided as inputs toa cashflow model (306). The cashflow model processes these inputs andgenerates an acquisition price corresponding to the consumer profile,vehicle type and rate of return which were input to the demand andcashflow models (308).

Referring to FIG. 4, a diagram illustrating the flow of data through acomparison engine in accordance with one embodiment is shown. Asdepicted in this figure, the acquisition price 210 generated by thedemand model is provided to a comparison engine 156. The comparisonengine also receives inventory records 131, each of which corresponds toa particular vehicle that is available to the automotive data processingsystem. Each of the vehicle inventory records identifies the purchaseprice for the corresponding vehicle, which is set by the seller of thevehicle. Comparison engine 156 compares the purchase price for eachinventory vehicle with the acquisition price and either qualifies ordisqualifies the vehicle based upon the comparison. If the purchaseprice is less than or equal to the acquisition price, the vehicle isqualified, and if the purchase price is greater than the acquisitionprice, the vehicle is disqualified. It should be noted that, althoughthe automotive data processing system may store inventory records forvehicles of many different types, acquisition price 210 is onlyapplicable to vehicles of the type originally input to the demand model(see FIGS. 2 and 3), so inventory records 131 are filtered so that onlyrecords for vehicles of the type input to the demand model are processedby comparison engine 156. The qualified vehicles may be identified bythe automotive data processing system in any suitable manner. Forinstance, qualified vehicle records may be separately stored, existinginventory records for qualified vehicles may be flagged, lists ofqualified vehicles may be stored, or any other type of indication of thequalified vehicles may be maintained. These indicators can then be usedto identify the qualified vehicles for presentation through a userinterface of the vehicle data application, while disqualified vehiclesare blocked from being displayed to consumers.

Referring to FIG. 5, a flow diagram illustrating a method for generatingdisplays of qualified vehicles in an automotive data processing systemuser interface in accordance with one embodiment is shown.

As depicted in this figure, the acquisition price that was previouslygenerated for the identified consumer profile and vehicle type isprovided to a comparison engine (502). Inventory records for vehiclesthat are available through the automotive data processing system arethen filtered to exclude vehicles other than the particular vehicle typeassociated with the acquisition price, and the filtered records areprovided to the comparison engine (504). The comparison engine comparesthe purchase price identified in each of the filtered vehicle records tothe received acquisition price (506). The comparison engine qualifies ordisqualifies each of the filtered vehicle records based on thecorresponding vehicle price and the acquisition price (508). Morespecifically, if the purchase price is less than or equal to theacquisition price, the vehicle is qualified, and if the purchase priceis greater than the acquisition price, the vehicle is disqualified. Anindication of the qualified vehicles (e.g., a list, copies of thevehicle records, or the like) is stored by the system. The automotivedata processing system then generates one or more displays to bepresented via a user interface of the vehicle data application (510).The displays include only qualified vehicles, so that if a usercompletes a transaction (e.g., lease) on one of these vehicles, it isensured that the transaction will meet the requirements (e.g., minimumreturn on investment) of the system operator. Disqualified vehicles(which would not meet these requirements on completion o foreignassociate transaction) are excluded from the generated displays.

As noted above, the acquisition price is associated with a particularconsumer profile and vehicle type. As it is determined whether eachvehicle is qualified or not, qualified vehicles are added to a list ofqualified vehicles for the corresponding consumer profile and vehicletype, while disqualified vehicles are not. This same process is repeatedfor each of a set of possible consumer profiles and vehicle types sothat multiple lists of qualified vehicles are stored by the system, witheach list being associated with a corresponding consumer profile andvehicle type. Then, when a specific consumer interacts with the system,one of the consumer profiles which is associated with the consumer isidentified, a vehicle type of interest to the consumer is identified,and the corresponding list of qualified vehicles is retrieved. This listis used to identify particular ones of the available inventory vehiclesof the desired type that are qualified for this specific consumer. Sinceonly vehicles that have acquisition prices at or below the acquisitionprice are qualified for display to the consumer through the application,any lease transactions that are completed necessarily involve vehiclesthat are priced at a level sufficient to provide the desired return forthe system operator.

It should be noted that “list”, as used herein, should be construed tocover lists, tables, databases, or any other data structures that arecapable of storing the qualified vehicles corresponding to eachcombination of consumer profile and vehicle type for the desired return.It should also be noted that the automotive data processing system maybe configured to store a list of payments generated by the demand modelfor corresponding combinations of consumer profiles and vehicle types.The automotive data processing system may further be configured to storea list of acquisition prices generated by the cashflow model forcorresponding combinations of consumer profiles and vehicle types for adesired return.

As mentioned above, the demand model is intended to identify a paymentat which a consumer having a particular profile is likely to complete alease transaction for a vehicle of a given type. In one embodiment, thedemand model is developed by examining portions of the historicaltransaction data corresponding to particular combinations of consumerprofile and vehicle type. The consumer profile may be defined by anysuitable set of values for a defined set of factors that mightpotentially drive the rate of default or return (e.g., FICO score,income, payment-to-income ratio, loan-to-value ratio, down paymentamount, recurring monthly payment amount, depreciation, vehicle yearmake model and miles, vehicle value, origination location, originationchannel (rideshare/consumer), etc.). The vehicle type may be defined byfactors such as make and model, or make, model and year.

In one embodiment, for each combination of consumer profile and vehicletype, the corresponding records in the historical transaction data canbe ranked according to the associated purchase prices. (In this case,the historical transaction data will include data for both convertedtransactions representing actual sales or leases and browsing or viewingtransactions that were not converted.) Then, a target price isdetermined by identifying the price corresponding to a specificpercentile of the completed transactions. For example, the 5thpercentile may correspond to a target price of $400. Thus, 5% of theconsumers that fall within the identified consumer profile will completea lease for a vehicle of the identified type if the lease price is $400.The selected percentile may be increased or decreased, which may in turnaffect the pace at which vehicles are leased through the application.For instance, if a greater percentile is selected (e.g., 6% instead of5%), the target price will be slightly lower, reflecting the greaternumber of consumers leasing at the target price. A similar analysis isperformed for each combination of consumer profile and vehicle type, sothat the demand model can, for each combination of these inputs, providea corresponding target price at which the selected percentile oftransactions will be converted.

The target price output by the demand model corresponding to theidentified consumer profile and vehicle type is provided as an input tothe cash flow model. The cash flow model is designed to determine thecash flow that is generated by a transaction for a particular type ofvehicle at a given price. In one embodiment, the vehicle data systemcollects information relating to all contracts for vehicle leases thatare made using the system. This information is then used to develop thecash flow model. The collected contract information is used todetermine, for a given vehicle type and at a given price, theprobabilities that a consumer will maintain the contract, return thevehicle, or default on the contract.

In one embodiment, the cash flow model is developed using a databasethat is created with attributes which are known at the point oforigination and which might potentially drive the rate of default orreturn on a contract, such as FICO score, start payment, regularpayment, vehicle year make model miles, vehicle value, originationlocation, origination channel (rideshare/consumer), etc. The status ofthe loan at the beginning and the end of each contract period (e.g.,defaulted, returned as agreed, actively paying) is also included.

The database contains a row for every contract for every due date frominception of the contract. For example, Rideshare contracts that involveweekly payments have one row per week for every account (e.g., 52 rowsfor a one year old account), while consumer loans which are due formonthly payments have 12 rows of status results for a year. In bothcases, the origination attributes are repeated on every row. Thedatabase may have hundreds of thousands of rows (records).

An analysis is performed on the records in the database to predict thelikelihood of return or default for any configuration of attributesknown at origination, for any period in the life of the subscription.The output is a formula that predicts the likelihood of default, return,or continued payment for every invoice period (typically for 36 monthsin the case of rideshare and 48 months in the case of consumer). In thisembodiment, it is assumed that after the full length of the loan period,the customers will return their vehicles.

An example of such a formula may be

g(Σ_(i=1) ^(N) _(f)(x _(i)β)),

where N is the number of feature attributes in the model, x is anattribute, β is some estimated coefficient and g is a functional form,and f is also a functional form such as a linear combination.

Based upon these probabilities, the expected net gross cash flow from acontract for this type of vehicle at this price can be determined. Theformula for the probabilities of default, return, or continued paymentis then put into a model that includes business costs, such as cost ofcapital, marketing, origination costs, servicing costs, depreciation,and liquidation costs. When these costs are added to the cost ofacquisition of the vehicle from the dealer, the result is a gross cashflow expectation for the vehicle.

When the details of any of the previously originated vehicles are inputto the model, the model might predict that, on average, the actualpayment results in an expected return that is very high. Alternatively,the expected return may possibly be negative. Thousands of deals aretherefore loaded, one by one, into the model, and are solved for atarget return by adjusting the regular payment, saving the regularpayment, and then using statistics on the deals with the ideal regularpayment (the one that results in the desired return) to develop ageneral formula using the known origination attributes as inputs todrive a payment appropriate for a deal on a particular type of vehicle.

In one embodiment, a separate filter (not included in the model) is usedto exclude certain vehicles which are not good fits with the consumer.For example, the vehicles may be excluded because the payment is notcompetitive, or because the vehicle is a type that is usually notpreferred by the consumer (e.g., pickup trucks are not usually preferredby uber drivers). These vehicles are considered outliers and may skewthe result that best fits the bulk of the vehicles.

As noted above, the acquisition price determined by the cash flow modelis used in the selection of qualified vehicles that can be displayed toa consumer. In one embodiment, the acquisition price for a particulartype of vehicle is compared to each of the vehicles of that type thathave been made available by sellers through the vehicle data system. Inthis embodiment, there are a predetermined set of consumer profiles intowhich a given consumer can be classified. For example, there may bethree consumer profiles corresponding to low risk, medium risk and highrisk consumers. The consumer profiles may segment the consumerpopulation in many different ways, and there may be any desired numberof different profiles. In this particular embodiment, the systemmaintains a list of qualified vehicles for each combination of consumerprofile and vehicle type, so that the vehicles which are qualified andcan be displayed to a particular consumer can be quickly identified anddisplayed in real time when the consumers profile is determined. Inother embodiments, the qualified vehicles can be dynamically determined.

Referring to FIG. 6, the use of the qualified vehicle list in accordancewith some embodiments is shown. As depicted in this figure, a consumerfirst logs onto a client application which interacts with the vehicledata application (602). The vehicle data application identifies theconsumer profile that is associated with the consumer (604) and thenretrieves the corresponding list of qualified vehicles from a data store(606). The consumer profile may be determined in one embodiment based oninformation that is derived from a user request to access the automotivedata processing system. For example, the user request may include aname, user ID, system registration ID, or other information that isunique to the particular consumer that is accessing the system. Thisidentifying information may be used to access consumer profileinformation that was previously provided to the system during aregistration process and stored by the system. Alternatively, theidentifying information may be used to access information that ispublicly available, or is collected and provided by external informationservices.

As noted above, each of the vehicles in the list has been compared to anacquisition price associated with the consumer profile, so it is notnecessary to separately qualify vehicles for each consumer, or to expendthe time and computational resources necessary to do so when theconsumer logs in. This allows the system to generate displays ofqualified vehicles to the consumer in real time. After retrieving thelist of qualified vehicles, the consumer may interact with the vehicledata application, such as by submitting vehicle queries (608). Inresponse to the consumer's queries, the vehicle data application willgenerate displays (e.g., vehicle listings) that are presented to theconsumer via a user interface (610). Because the vehicles that aredisplayed to the consumer responsive to these queries or in the courseof browsing are only selected from the qualified vehicles that werepreviously identified by the vehicle data application, it is assuredthat any transaction completed by the consumer on one of these vehicleswill provide the return desired by the system operator.

It should be noted that the sellers of the vehicles may be provided withthe ability to view the vehicles that are displayed to users havingparticular consumer profiles, and may therefore be able to determinewhether or not particular vehicles that they have made available forpurchase or lease through the vehicle data system are qualified fordisplay. If a seller determines that a particular vehicle is not beingdisplayed to consumers having a particular profile, the seller maychange the purchase price of the vehicle in order to ensure that thevehicle is qualified. For example, if the seller prices a particularvehicle at $25,000, but the acquisition price is $24,500, the vehiclewill not be qualified and consequently will not be presented to theconsumer. The seller may therefore reduce the price to $24,500 or lessin order to have the vehicle presented to the consumer. In oneembodiment, the seller may use a client application which includes atool such as a slider bar to adjust the price to a level which is at orbelow the acquisition price corresponding to that type of vehicle,thereby allowing the vehicle to be qualified and displayed to consumers.

Embodiments of the automotive data processing system may be implementedin a variety of different computing systems. FIG. 7 depicts adiagrammatic representation of a distributed network computingenvironment where embodiments disclosed can be implemented. In theexample illustrated, network computing environment 700 includes network704 that can be bi-directionally coupled to a client computing device714, a server system 716 and one or more third party system 717. Serversystem 716 can be bi-directionally coupled to data store 718. Network704 may represent a combination of wired and wireless networks thatnetwork computing environment 700 may utilize for various types ofnetwork communications known to those skilled in the art.

For the purpose of illustration, a single system is shown for each ofclient computing device 714 and server system 716. However, a pluralityof computers may be interconnected to each other over network 704. Forexample, a plurality client computing devices 714 and server systems 716may be coupled to network 704.

Client computer device 714 can include central processing unit (“CPU”)720, read-only memory (“ROM”) 722, random access memory (“RAM”) 724,hard drive (“HD”) or storage memory 726, and input/output device(s)(“I/O”) 728. I/O 728 can include a keyboard, monitor, printer,electronic pointing device (e.g., mouse, trackball, stylus, etc.), orthe like. In one embodiment I/O 728 comprises a touch screen interfaceand a virtual keyboard. Client computer device 714 may implementsoftware instructions to provide a client application configured tocommunicate with an automotive data processing system. Likewise, serversystem 716 may include CPU 760, ROM 762, RAM 764, HD 766, and I/O 768.Server system 716 may implement software instructions to implement avariety of services for an automotive data processing system. Theseservices may utilize data stored in data store 718 and obtain data fromthird party systems 717. Many other alternative configurations arepossible and known to skilled artisans.

Each of the computers in FIG. 7 may have more than one CPU, ROM, RAM,HD, I/O, or other hardware components. For the sake of brevity, eachcomputer is illustrated as having one of each of the hardwarecomponents, even if more than one is used. Each of computers 714 and 716is an example of a data processing system. ROM 722 and 762; RAM 724 and764; HD 726, and 766; and data store 718 can include media that can beread by CPU 720 or 760. Therefore, these types of memories includenon-transitory computer-readable storage media. These memories may beinternal or external to computers 714 or 716.

Portions of the methods described herein may be implemented in suitablesoftware code that may reside within ROM 722 or 762; RAM 724 or 764; orHD 726 or 766. The instructions may be stored as software code elementson a data storage array, magnetic tape, floppy diskette, optical storagedevice, or other appropriate data processing system readable medium orstorage device.

While the foregoing embodiments were provided primarily in the contextof an automotive data processing system, it will be appreciated thatembodiments described herein may be applied to other assets (e.g.,real-estate, boats, etc.). In particular, embodiments may be adapted forassets for which depreciation can be modeled. Moreover, those skilled inthe relevant art will appreciate that the invention can be implementedor practiced with other computer system configurations, includingwithout limitation multi-processor systems, network devices,mini-computers, mainframe computers, data processors, and the like. Theinvention can be embodied in a computer or data processor that isspecifically programmed, configured, or constructed to perform thefunctions described in detail herein. The invention can also be employedin distributed computing environments, where tasks or modules areperformed by remote processing devices, which are linked through acommunications network such as a local area network (LAN), wide areanetwork (WAN), and/or the Internet. In a distributed computingenvironment, program modules or subroutines may be located in both localand remote memory storage devices. These program modules or subroutinesmay, for example, be stored or distributed on computer-readable media,including magnetic and optically readable and removable computer discs,stored as firmware in chips, as well as distributed electronically overthe Internet or over other networks (including wireless networks).

ROM, RAM, and HD are computer memories for storing computer-executableinstructions executable by the CPU or capable of being compiled orinterpreted to be executable by the CPU. Suitable computer-executableinstructions may reside on a computer readable medium (e.g., ROM, RAM,and/or HD), hardware circuitry or the like, or any combination thereof.Within this disclosure, the term “computer readable medium” is notlimited to ROM, RAM, and HD and can include any type of data storagemedium that can be read by a processor. Examples of computer-readablestorage media can include, but are not limited to, volatile andnon-volatile computer memories and storage devices such as random accessmemories, read-only memories, hard drives, data cartridges, directaccess storage device arrays, magnetic tapes, floppy diskettes, flashmemory drives, optical data storage devices, compact-disc read-onlymemories, and other appropriate computer memories and data storagedevices. Thus, a computer-readable medium may refer to a data cartridge,a data backup magnetic tape, a floppy diskette, a flash memory drive, anoptical data storage drive, a CD-ROM, ROM, RAM, HD, or the like.

Any suitable programming language can be used to implement the routines,methods or programs of embodiments of the invention described herein.Other software/hardware/network architectures may be used. For example,the functions of the disclosed embodiments may be implemented on onecomputer or shared/distributed among two or more computers in or acrossa network. Communications between computers implementing embodiments canbe accomplished using any electronic, optical, radio frequency signals,or other suitable methods and tools of communication in compliance withknown network protocols.

Different programming techniques can be employed such as procedural orobject oriented. Any particular routine can execute on a single computerprocessing device or multiple computer processing devices, a singlecomputer processor or multiple computer processors. Data may be storedin a single storage medium or distributed through multiple storagemediums, and may reside in a single database or multiple databases (orother data storage techniques). Although the steps, operations, orcomputations may be presented in a specific order, this order may bechanged in different embodiments. In some embodiments, to the extentmultiple steps are shown as sequential in this specification, somecombination of such steps in alternative embodiments may be performed atthe same time. The sequence of operations described herein can beinterrupted, suspended, or otherwise controlled by another process, suchas an operating system, kernel, etc. The routines can operate in anoperating system environment or as stand-alone routines. Functions,routines, methods, steps and operations described herein can beperformed in hardware, software, firmware or any combination thereof.

Embodiments described herein can be implemented in the form of controllogic in software or hardware or a combination of both. The controllogic may be stored in an information storage medium, such as acomputer-readable medium, as a plurality of instructions adapted todirect an information processing device to perform a set of stepsdisclosed in the various embodiments. Based on the disclosure andteachings provided herein, a person of ordinary skill in the art willappreciate other ways and/or methods to implement the invention.

It is also within the spirit and scope of the invention to implement insoftware programming or code an of the steps, operations, methods,routines or portions thereof described herein, where such softwareprogramming or code can be stored in a computer-readable medium and canbe operated on by a processor to permit a computer to perform any of thesteps, operations, methods, routines or portions thereof describedherein. The invention may be implemented by using software programmingor code in one or more digital computers, by using application specificintegrated circuits, programmable logic devices, field programmable gatearrays, optical, chemical, biological, quantum or nanoengineeredsystems, components and mechanisms may be used. The functions of theinvention can be achieved by distributed or networked systems.Communication or transfer (or otherwise moving from one place toanother) of data may be wired, wireless, or by any other means.

As used herein, the terms “comprises,” “comprising,” “includes,”“including,” “has,” “having” or any other variation thereof, areintended to cover a non-exclusive inclusion. For example, a process,article, or apparatus that comprises a list of elements is notnecessarily limited only those elements but may include other elementsnot expressly listed or inherent to such process, article, or apparatus.Further, unless expressly stated to the contrary, “or” refers to aninclusive or and not to an exclusive or. For example, a condition “A orB” is satisfied by any one of the following: A is true (or present) andB is false (or not present), A is false (or not present) and B is true(or present), and both A and B are true (or present).

To the extent particular values are provided in any example embodimentsin the description, such values are provided by way of example and notlimitation. Moreover, while in some embodiments rules may use hardcodedvalues, in other embodiments rules may use flexible values. In oneembodiment, one or more of the values may be specified in a registry,allowing the value(s) to be easily updated without changing the code.The values can be changed, for example, in response to analyzing systemperformance.

Additionally, any examples or illustrations given herein are not to beregarded in any way as restrictions on, limits to, or expressdefinitions of, any term or terms with which they are utilized. Instead,these examples or illustrations are to be regarded as being describedwith respect to one particular embodiment and as illustrative only.Those of ordinary skill in the art will appreciate that any term orterms with which these examples or illustrations are utilized willencompass other embodiments which may or may not be given therewith orelsewhere in the specification and all such embodiments are intended tobe included within the scope of that term or terms. Language designatingsuch nonlimiting examples and illustrations includes, but is not limitedto: “for example,” “for instance,” “e.g.,” “in one embodiment.”

Benefits, other advantages, and solutions to problems have beendescribed above with regard to specific embodiments. However, thebenefits, advantages, solutions to problems, and any component(s) thatmay cause any benefit, advantage, or solution to occur or become morepronounced are not to be construed as a critical, required, or essentialfeature or component.

What is claimed is:
 1. A method implemented in an automotive dataprocessing system, the method comprising: providing a demand model,wherein in response to receiving input identifying a consumer profileand a vehicle type, the demand model is configured to generate acorresponding payment as an output; providing a cashflow model, whereinin response to receiving the payment output by the demand model andinput identifying a desired return on a converted vehicle transaction,the cashflow model is configured to generate an acquisition price as anoutput; and providing a comparison engine, wherein in response toreceiving the acquisition price output by the cashflow model, thecomparison engine is configured to retrieve a set of vehicle inventoryrecords, for each of the vehicle inventory records, compare acorresponding purchase price to the acquisition price and generate anindication of whether or not a vehicle corresponding to the vehicleinventory record is qualified, and generate a list of qualifiedvehicles.
 2. The method of claim 1, further comprising generating, foreach of a plurality of unique combinations of consumer profiles andvehicle types, a corresponding list of qualified vehicles and storingthe lists of qualified vehicles.
 3. The method of claim 2, furthercomprising, in response to a user request of a specific consumer:identifying one of the consumer profiles that is associated with thespecific consumer; identifying a vehicle type associated with the userrequest; retrieving one of the lists of qualified vehicles whichcorresponds to the identified one of the consumer profiles and theidentified vehicle type; and generating a display which is presented ina user interface of a client computing device, wherein the displayincludes one or more qualified vehicles in the retrieved one of thelists of qualified vehicles and excludes disqualified vehicles.
 4. Themethod of claim 1, further comprising generating a display which ispresented in a user interface of a client computing device, wherein thedisplay includes one or more of the qualified vehicles and excludesdisqualified vehicles.
 5. The method of claim 1, wherein the comparisonengine is configured to determine that each vehicle is qualified if thecorresponding purchase price is no more than the acquisition price, andis otherwise disqualified.
 6. The method of claim 1, wherein the demandmodel is configured to generate the payment by: identifying, in acollection of historical transaction records, a subset of the historicaltransaction records that correspond to the combination of the consumerprofile and the vehicle type; ranking the subset of historicaltransaction records by corresponding prices; and selecting as thepayment a target price corresponding to a desired percentile ofconverted transactions represented by the historical transactionrecords.
 7. An automotive data processing system comprising: one or moreprocessors communicatively coupled to one or more data storage devices,the one or more processors coupled to a non-transitory computer-readablemedium that stores instructions which are executable by the processor tocause the processor to execute: a demand model, wherein in response toreceiving input identifying a consumer profile and a vehicle type, thedemand model is configured to generate a corresponding payment as anoutput; a cashflow model, wherein in response to receiving the paymentoutput by the demand model and input identifying a desired return on aconverted vehicle transaction, the cashflow model is configured togenerate an acquisition price as an output; and a comparison engine,wherein in response to receiving the acquisition price output by thecashflow model, the comparison engine is configured to retrieve a set ofvehicle inventory records, for each of the vehicle inventory records,compare a corresponding purchase price to the acquisition price andgenerate an indication of whether or not a vehicle corresponding to thevehicle inventory record is qualified, and generate a list of qualifiedvehicles
 8. The automotive data processing system of claim 7, whereinthe instructions are further executable by the processor to generate,for each of a plurality of unique combinations of consumer profiles andvehicle types, a corresponding list of qualified vehicles and storingthe lists of qualified vehicles.
 9. The automotive data processingsystem of claim 8, wherein the instructions are further executable bythe processor to, in response to a user request of a specific consumer:identify one of the consumer profiles that is associated with thespecific consumer; identify a vehicle type associated with the userrequest; retrieve one of the lists of qualified vehicles whichcorresponds to the identified one of the consumer profiles and theidentified vehicle type; and generate a display which is presented in auser interface of a client computing device, wherein the displayincludes one or more qualified vehicles in the retrieved one of thelists of qualified vehicles and excludes disqualified vehicles.
 10. Theautomotive data processing system of claim 7, wherein the instructionsare further executable by the processor to generate a display which ispresented in a user interface of a client computing device, wherein thedisplay includes one or more of the qualified vehicles and excludesdisqualified vehicles.
 11. The automotive data processing system ofclaim 7, wherein the comparison engine is configured to determine thateach vehicle is qualified if the corresponding purchase price is no morethan the acquisition price, and is otherwise disqualified.
 12. Theautomotive data processing system of claim 7, wherein the demand modelis configured to generate the payment by: identifying, in a collectionof historical transaction records, a subset of the historicaltransaction records that correspond to the combination of the consumerprofile and the vehicle type; ranking the subset of historicaltransaction records by corresponding prices; and selecting as thepayment a target price corresponding to a desired percentile ofconverted transactions represented by the historical transactionrecords.
 13. A computer program product for generating vehicleencodings, the computer program product comprising a non-transitorycomputer-readable medium storing instructions executable by a processorto cause the processor to perform: providing a demand model, wherein inresponse to receiving input identifying a consumer profile and a vehicletype, the demand model is configured to generate a corresponding paymentas an output; providing a cashflow model, wherein in response toreceiving the payment output by the demand model and input identifying adesired return on a converted vehicle transaction, the cashflow model isconfigured to generate an acquisition price as an output; and providinga comparison engine, wherein in response to receiving the acquisitionprice output by the cashflow model, the comparison engine is configuredto retrieve a set of vehicle inventory records, for each of the vehicleinventory records, compare a corresponding purchase price to theacquisition price and generate an indication of whether or not a vehiclecorresponding to the vehicle inventory record is qualified, and generatea list of qualified vehicles.
 14. The computer program product of claim13, further comprising generating, for each of a plurality of uniquecombinations of consumer profiles and vehicle types, a correspondinglist of qualified vehicles and storing the lists of qualified vehicles.15. The computer program product of claim 14, further comprising, inresponse to a user request of a specific consumer: identifying one ofthe consumer profiles that is associated with the specific consumer;identifying a vehicle type associated with the user request; retrievingone of the lists of qualified vehicles which corresponds to theidentified one of the consumer profiles and the identified vehicle type;and generating a display which is presented in a user interface of aclient computing device, wherein the display includes one or morequalified vehicles in the retrieved one of the lists of qualifiedvehicles and excludes disqualified vehicles.
 16. The computer programproduct of claim 13, further comprising generating a display which ispresented in a user interface of a client computing device, wherein thedisplay includes one or more of the qualified vehicles and excludesdisqualified vehicles.
 17. The computer program product of claim 13,wherein the comparison engine is configured to determine that eachvehicle is qualified if the corresponding purchase price is no more thanthe acquisition price, and is otherwise disqualified.
 18. The computerprogram product of claim 13, wherein the demand model is configured togenerate the payment by: identifying, in a collection of historicaltransaction records, a subset of the historical transaction records thatcorrespond to the combination of the consumer profile and the vehicletype; ranking the subset of historical transaction records bycorresponding prices; and selecting as the payment a target pricecorresponding to a desired percentile of converted transactionsrepresented by the historical transaction records.